home *** CD-ROM | disk | FTP | other *** search
/ Disc to the Future 2 / Disc to the Future Part II Programmer's Reference (Wayzata Technology)(6013)(1992).bin / MAC / THINKC / 3_0 / MIDIMERG / README < prev   
Text File  |  1988-12-09  |  4KB  |  109 lines

  1. MIDIMERGER 1.0
  2. ~~~~~~~~~~~~~~
  3. MidiMerger is a LSC package which I designed for use in synthesiser
  4. voice editing packages. It allows data from a keyboard or
  5. external device to be echoed to the output MIDI device, merged
  6. with any data generated by the Mac. For example, the input
  7. device might be a master keyboard, the output device an expander.
  8.  
  9.     The routines will drive either or both serial
  10. ports in whatever combination you want, so you can (for
  11. example) echo MODEM in to PRINTER out, and vice versa, merging
  12. Mac. generated data with either.
  13.  
  14.     MidiMerger DOESN'T
  15.         -    let you see the data coming from the external device;
  16.             I'm assuming you don't care about this;
  17.         -    associate timing information with input data.
  18. Both of these functions can be obtained from the assember MIDI.Lib
  19. module which MidiMerger uses.
  20.  
  21.     I don't know of any bugs. I've tested the merging code in
  22. MODEM=>MODEM and PRINTER=>PRINTER configurations, but not cross-wise.
  23. If you have two MIDI interfaces (lucky devil!), please try it.
  24. Currently, MidiMerger throws away active sensing bytes. This is because
  25. MidiMerger relies on your application calling idleMidi() as often as
  26. possible to echo everything. If you pull down a menu, you don't get to
  27. call idleMidi(), and if your keyboard was sending out active sensing,
  28. the destination device cuts off. I do echo through all the other system
  29. realtime messages though, such as the MIDI clock. Of course, everything
  30. will stop if you're using MIDI clock and pull down a menu...
  31.     MidiMerger understands (as far as I can ascertain) MIDI Timecode (MTC);
  32. well, at least, it knows that F1 1/4-frame messages have two following
  33. bytes. I can't think of any other part of
  34. the MIDI spec which is under development and liable to break things - as
  35. far as I know, the other extensions have taken place within the System
  36. Exclusive framework.
  37.  
  38. MidiMerger FreeWare by Nick Rothwell, 1988. The underlying MIDI
  39. assembler routines aren't mine, though, they're Kirk Austin's.
  40. Do what you like with MidiMerger, give it to your friends, etc. I'd quite
  41. like a mention in your about-box if you do use this stuff, and if you make
  42. alterations, please make them clear, so we don't have several zillion
  43. differently functional versions floating around. Otherwise, you can
  44. contact me as follows:
  45.  
  46.                     Nick Rothwell
  47.                     3/13 Forrest Hill
  48.                     Edinburgh EH1 2QL
  49.                     Scotland, UK.
  50.                     nick@lfcs.ed.ac.uk
  51.                     nick%lfcs.ed.ac.uk@uk.ac.ucl.cs.nss
  52.  
  53. Sorry? Oh yes, the routines. Ok, here we go:
  54.  
  55.     typedef enum {
  56.         MODEM, PRINTER
  57.     } PORT;
  58.     
  59. Enumerated type for the ports. MidiMerger will run either or both ports;
  60. but, don't start doing operations on a port you haven't initialised.
  61.  
  62.  
  63.     extern void startMidi(PORT port);
  64.     extern void stopMidi(PORT port);
  65.     
  66. Initialise and terminate a port for MIDI operations. Be sure to wind down
  67. a port you've initialised, even within crash routines, as you don't want
  68. the interrupt handles hanging around if you exit.
  69.  
  70.  
  71.     extern void channelise(PORT port, int channel);
  72.     extern void noChannelise(PORT port);
  73.     
  74. MIDI data from either or both ports can be channelised, so that it
  75. appears to be transmitted on that channel. This should probably be
  76. done on output rather than input. The difference is important - if you
  77. have a keyboard on both ports, and an expander on both ports, then
  78. you can channelise either or both keyboards, but not selectively on
  79. the expanders. channel ranges from 1 to 16.
  80.  
  81.  
  82.     extern void transmitMidi(PORT port, BYTE *message);
  83.     
  84. Transmit a MIDI message to a port. transmitMidi knows about the format
  85. of messages, so the length doesn't need to be specified. message should
  86. point to the status byte of a MIDI message. System Exclusives, being of
  87. indeterminate length, must be terminated by EOX (0xF7).
  88.  
  89.  
  90.     extern void idleMidi(PORT input, PORT output);
  91.  
  92. This is the *crucial* routine - it is responsible for echoing data from
  93. input port to output. Think of it like SystemTask() - call it as often
  94. as possible if you want your keyboard echoed reliably.
  95.     idleMidi can echo from either port to either port. You might wish to
  96. put in a call like
  97.  
  98.     idleMidi(MODEM, MODEM);
  99.     idleMidi(PRINTER, PRINTER);
  100.     
  101. if you have both ports active.
  102.    idleMidi and transmitMidi are atomic wrt. the MIDI messages.
  103. transmitMidi sends an entire message. idleMidi, if it sees a message, will
  104. take control until the entire message has been echoed. This is probably
  105. not optimal, but is simplest way to do it.
  106.  
  107.  
  108.                 Nick.
  109.